New vray framebuffer doesn`t apply adjustments to render elements.

[dans]

Yes, it will be included in the upcoming hotfix 3 (V-Ray 5.1.3). You'll have an official version with it very soon

I had a look into this right away and see several issues with this (major for me):

• when saving from the framebuffer UI as seperate channels the option is ignored
• you can not show the channels in the framebuffer as they will be saved when the new option is enabled (WYSIWYG fail)
• SDK: There is still no way to call PixelBufferInterface::getChannelPixels in a way that provide the color corrected channel data? I only see a new flag IWI_APPLY_CC_TO_ELEMENTS for the image writer interface. It is not usable for plugins requesting data from the framebuffer directly this way (as in my psd-manager render effect). The PixelBufferInterface API works in all previous V-Ray versions as expected. Since the new V-Ray 5 VFB2 it stopped applying the color corrections except to the effectsResult channel or when enabling the old VFB via VRAY_VFB2_ENABLED=0. Which so far was at-least consistent with the VFB display (but it did not allow to enforce color correction as users requested here in this thread).
• Because of this remaining SDK issue my plugin psd-manager still can not request color corrected pixels of the elemnts (the option is ignored by V-Ray). I can only force things off, not on. I guess the button to save to seperate files from the VFB UI now behaves inconsistent for just the same reason.

Why was no global option added instead of one just for the image writer? It would have affected framebuffer display, saving and plugin API the same everywhere and provide consistent behaviour. Plugins could still request image data that has no color corrections applied using the existing flags in the API (as in all previous versions).
Please do a proper fix with backward compatibility and usability in mind and do not further complicate what gets saved by V-ray and how. It is already inconsistent and confusing as is for the users.

[yavor.rubenov]

when saving from the framebuffer UI as seperate channels the option is ignored

As this is UI - there's the possibility for choice. We'll be adding options so that you can choose - save with corrections or not.
It won't make much sense to use the option from the render setup as it is part of the scene - say you open some scene in which the option is set but then load some history image that you rendered from a scene that had the option off.. or you load some external image and do corrections on it.

SDK: There is still no way to call PixelBufferInterface::getChannelPixels in a way that provide the color corrected channel data?

Since 5.0 there are two PixelBufferInterface::getChannelPixels methods - one with multiple parameters and one with a single callback parameter.
If you look in the SDK with those newer builds you will see that the first one has a big comment - it is deprecated and will be removed in the future and that you should use the one with the single callback parameter. That callback parameter allows for multiple improvements:

• allows for multithreading when applying color corrections - in some cases this gives up to 4x faster saves
• easily allows extensions without breaking the sdk - for example in those newer versions we've added a flag if corrections should be applied to all channels or not (cbFlags_ApplyCCsToChannels)

[kosso_olli]

• you can not show the channels in the framebuffer as they will be saved when the new option is enabled (WYSIWYG fail)

I did not notice this while testing, but indeed you are right. This is bad.

Please do a proper fix with backward compatibility and usability in mind and do not further complicate what gets saved by V-ray and how. It is already inconsistent and confusing as is for the users.

Agreed. It will cause trouble when a user is saving through the UI of the VFB and then is wondering why the output is looking so different.